%\section{Justificaci\'on de la Arquitectura}
\section{Arquitectura}

%Documento que describa las principales decisiones de
%arquitectura que fueron evaluadas y la decisión que se tomó
%en cada caso. Se deberá incluir una o más vistas que
%describan la visión general de cómo será el producto en el
%nivel de la arquitectura.

\textsl{En esta secci\'on presentaremos una posible arquitectura para
el sistema, junto con una explicaci\'on de su funcionamiento y una
justificaci\'on.}

%\subsection{Arquitectura}

\subsection{Sistema no al troll}

\begin{figure}[H]
    \centering
    \subfloat[Sistema no al troll]
    {\includegraphics[width=0.9 \textwidth]{./img/todo.pdf}}
\end{figure}


Aclaraciones previas: 
En esta sección, cuando hablemos de usuario, siempre es con referencia al usuario del sistema, los que nos contrataron para realizar el proyecto.
Mientras que cuando hablemos de invididuos publicadores, nos referiremos a los individuos capaces de publicar comentarios potencialmente dañinos o troll.

\vspace*{0.3cm}

Para empezar, existen distintos conectores que relacionan al Sistema No Al Troll con el Front End Web.
Como se puede observar, tenemos un conector cliente/servidor con encriptación de datos (ya que los datos ingresados son 
sensibles) hacia el autenticador del sistema. 

Se aplicó la táctica de Seguridad ``Maintain data confidenciality''.
Esto es porque dentro de los individuos publicadores que acceden al sistema, algunos querrán autenticarse ingresando su usuario y contraseña. 

\vspace*{0.3cm}

El autenticador irá atendiendo los distintos pedidos verificando con la base de datos de usuarios registrados si el nombre de usuario y contraseña
ingresados coinciden con un usuario existente. Más allá de que la autenticación haya sido pedida por los stakeholders, es importante resaltar que el 
sistema pone en uso de esta manera, la táctica de seguridad ``authenticate users'' para brindar mayor seguridad al mismo.

\vspace*{0.3cm}

El hecho de que un individuo publique un nuevo comentario se ve reflejado en el pipe con encriptación entre el Front End y los Procesadores de Comentarios del sistema. 

Se agregó encriptación dado que cuando un individuo publicador se conecta al sistema vía una red social, el comentario ingresado tiene en su header detallado el nombre
de usuario y contraseña de la red social correspondiente.
Esto es para luego publicar dicho comentario en su perfil de red social usando esa autenticación.

Nuevamente estamos aplicando la misma táctica de seguridad que mencionamos anteriormente, ``authenticate users''. 

\vspace*{0.3cm}

Se utilizó un pipe del que varios procesadores desencolan comentarios para procesarlos y ver si son publicables o no. 
Se usaron varios procesadores para mejorar la performance y la velocidad de respuesta de los comentarios hacia el individuo publicador (por aprobado o 
rechazado). 

\vspace*{0.3cm}

Los procesadores fueron proporcionados por el grupo externo de investigación,  por lo que saben procesar todo tipo de archivos: 
video/audio/texto/links/etc. Pueden saber de que archivo se trata mirando el header de cada comentario ingresado (veremos como éste dato figura en el
header cuando veamos el front end web desde donde llegan al sistema).

\vspace*{0.3cm}

Los procesadores procesan los comentarios y los publican en un bus al que se encuentran suscriptos, entre otros componentes, el
manager de resultados de comentarios. Este se encarga de informarle al front end si el comentario encolado anteriormente fue publicado con éxito o rechazado por el sistema.

\vspace*{0.3cm}

También hay un pipe desde el front end web hasta el administrador de reputación, significando un pedido de incremento de reputación de un usuario determinado
ya que se registró un ``me gusta'' por parte de otro usuario a una de sus publicaciones.

\vspace*{0.3cm}

El Front End tiene permiso de lectura sobre la base con las configuraciones de filtros disponibles que proporciona el sistema, para que los usuarios 
elijan su propia configuración según sus gustos personales.

\vspace*{0.3cm}

Por ultimo, el Front End es capaz de leer los comentarios aceptados por los procesadores de comentarios, pero previamente se les aplica un filtro según
la configuración de filtros ofensivos. Para ello, se conectan via cliente-servidor al filtrador de lectura
de comentarios el cual hace esta tarea leyendo las configuraciones segun el usuario solicitante. 

Hay varios filtradores para poder atender las solicitudes
más eficientemente.

\vspace*{0.3cm}

Dejando de lado el Front End, miremos que sucede cuando un comentario es publicado en el bus por un procesador de comentarios.


El bus tiene cuatro suscriptores: el manager de resultados (ya lo explicamos previamente), el administrador de reputación, el publicador de comentarios 
aceptados en redes sociales y el almacenador en base de datos.


El administrador de reputación solo se suscribe a comentarios aceptados por los procesadores y que hacen referencia a comentarios de otros usuarios para moderar 
su reputación (lo veremos en detalle más adelante).

\vspace*{0.3cm}

El publicador de comentarios aceptados en redes sociales, como su nombre lo indica, se suscribe a los comentarios aceptados por los procesadores. Mirando el header que
mencionamos antes donde se encuentra el nombre de usuario y contraseña de la red social,
se accede via cliente servidor a la red para publicar el comentario en el perfil de dicho usuario.

\vspace*{0.3cm}

Por último, el almacenador en base de datos se suscribe a comentarios rechazados y aceptados para guardarlo en la base de datos que corresponda.

\vspace*{0.3cm}

El sistema también cuenta con una interfaz de data mining que puede acceder a las bases de datos donde se almacenan sólo los comentarios, y no a otras donde
se almacenan los datos sensibles como información, nombre de usuario y contraseña de los individuos publicadores. 

De esta manera se aplica la táctica de seguridad 
``limit exposure'', permitiendo el acceso a la información que realmente interesa para aplicar datamining.

\vspace*{0.3cm}

De manera similar, se cuenta con una interfaz de malware, la cual está conectada al filtro de malware. Los comentarios a filtrar por malware, se envian por un call-return a la interfaz de malware, y es ésta quien decide si el comentario es dañino o no.

\vspace*{0.3cm}

Por último, se cuenta con un Front End para los administradores del sistema, los cuales deben autenticarse previamente vía el autenticador del sistema con una 
conexión cliente-servidor. Los administradores cuentan con permisos de lectura y escritura sobre todas las bases de datos.

\vspace*{0.3cm}

Los administradores realizan semanalmente una "bajada" de datos de las bases de comentarios para hacer backup (sobre todo de los rechazados) e ir renovando (eliminando) 
de las mismas los comentarios viejos, de modo de alivianar la carga de las bases de datos. A su vez pueden moderar las reputaciones de los individuos publicadores e inscribir/desinscribir
usuarios (incluyendo publicadores) registrados accediendo a la base de datos de usuarios.


Se aplicó la táctica de seguridad ``limit exposure'', creando un front end distinto del de los usuarios para los administradores para evitar posibles ataques vía front end web
de usuarios e individuos publicadores (los atacantes tendrían que conocer desde donde acceden los administradores).


\subsection{Front End}

El Front End Web para los usuarios cuenta con varios servidores web que se encargan de recibir las solicitudes de conexión de tipo cliente-servidor
de los distintos usuarios o individuos publicadores representadas a través de navegadores web.

Los servidores cuentan con redundancia pasiva, para poner otro servidor a recibir pedidos inmediatamente si alguno deja de funcionar, aplicando la táctica
de disponibilidad ``Passive Redundancy''.

\vspace*{0.3cm}

En la interacción con el servidor web, los usuarios acceden a las diferentes pantallas de la interfaz gráfica desde donde pueden realizar diferentes tipos
de acciones con el sistema. 

Por ejemplo, las líneas punteadas que se ven en el diagrama que van desde y hacia el sistema con el servidor representan
la lectura de las configuraciones disponbiles de filtros de moderación de comentarios y el seteo de las configuraciones deseadas por el usuario, respectivamente.

\vspace*{0.3cm}

El conector cliente-servidor con encripción de datos se corresponde con la conexión al autenticador del sistema que vimos en el diagrama anterior. Al mismo
deben acceder los usuarios para identificarse, para poder setear los filtros de publicaciones deseados. Para los individuos publicadores, esta autenticación
será opcional.

\vspace*{0.3cm}

Asimismo, los individuos publicadores  pueden optar por autenticarse mediante una red social, para lo cual el servidor correspondiente le solicita al autenticador de redes sociales
que identifique al individuo publicador utilizando la red social seleccionada. 

El autenticador de redes sociales se conecta con la red social indicada para verificar la identidad
del individuo y le informa el resultado al servidor.

\vspace*{0.3cm}

También hay un conector pipe para que al detectar que un individuo publicador hace ``me gusta'' a un comentario de otro diferente, informarselo al sistema para incrementar
la reputación de este último individuo. La funcionalidad se vió previamente en la explicación del sistema No Al Troll.
Asumimos que los individuos publicadores que no ingresan vía red social no pueden realizar ``me gusta'', +1, etc.

\begin{figure}[H]
    \centering
    \subfloat[]
    {\includegraphics[width=0.9 \textwidth]{./img/front_end_pape.pdf}}
\end{figure}

Para el envío de comentarios, los servidores web encolan comentarios a moderar en un pipe del etiquetador de archivos, para indicar a que tipo de archivo
corresponde (video/audio/etc). De esta manera los procesadores saben, mirando el header del comentario enviado, de que tipo de comentario se trata.
Una vez etiquetados se encolan en el pipe del Despachador de comentarios para luego ser encriptados y enviados al sistema para su publicación o rechazo.

\vspace*{0.3cm}

Por último, el sistema informa si un comentario fue publicado o no mediante un conector asincrónico hacia el servidor (mirando el diagrama del sistema, esta
respuesta la envía el Manager de resultados de comentarios, que ya vimos).

\vspace*{0.3cm}

A modo de mejorar la comprensi\'on, y saliendo un poco de la formalidad del diagrama de componentes y conectores, se agregó una vista ``h\'ibrida'' donde se ven las distintas
``páginas'' de la interfaz web, representadas con el prefijo de módulo que dejan más en claro el motivo de cada conector y función de cada conector con el sistema.

\begin{figure}[H]
    \centering
    \subfloat[]
    {\includegraphics[width=0.9 \textwidth]{./img/front_end_original.pdf}}
\end{figure}

\newpage
\subsection{Procesador de Comentarios}

Los procesadores de comentarios desencolan comentarios enviados a publicar desde un pipe con encriptación.
Cada procesador cuenta con varios filtros que evalúa si el comentario engloba distintos contenidos que se desean filtrar. Gracias al header con el que
ingresan los comentarios en la cola, se puede saber de que tipo de archivo se trata.

\vspace*{0.3cm}

Primero, son pasados a un etiquetador.
Este etiquetador les agrega al header los filtros que se deben aplicar para ese comentario, leyendo la configuración del usuario que configuró los filtros que desaeaba aplicar,
de la base de configuraciones por usuario.

\vspace*{0.3cm}

Cada filtro chequea si debe actuar o no mirando el header modificado por el etiquetador. De detectar algún contenido que cumpla los requisitos
del filtro, el comentario es ``taggeado'' en su header como rechazado junto con su motivo de rechazo (alguna evidencia encontrada en el comentario) y publicado en el bus de datos.

\vspace*{0.3cm}

El último filtro es el de detección de malware, en caso de que el comentario haya sido etiquetado como para detección de este tipo de amenazas, el filtro se conecta vía call/return
con la interfaz de malware desde la cual los usuarios de la empresa de malware contratada evalúan de alguna manera si el comentario es perjudicial o no para el sistema.

Decidimos poner este filtro al final dado que la conexión call/return puede ser un cuello de botella y resultaba mejor filtrar todos los comentarios posibles utilizando los filtros anteriores
de manera de alivianar la cantidad de comentarios que deben pasar por este último.

\vspace*{0.3cm}

Si el comentario logra pasar todos los filtros, el último filtro publica el comentario en el bus con un header de ``aprobado''.
Es importante notar que aplicamos el estilo pipe and filters para esta parte, de modo de facilitar la modificabilidad de los mismos.
Es decir, si los administradores deciden cambiar la cantidad de filtros disponibles (por más o por otros distintos) es fácil agregar o quitar filtros utilizando
este estilo.

\vspace*{0.3cm}

Una vez que los comentarios son publicados en el bus de datos con el header de aprobado o rechazado, existen varios suscriptores que se suscriben a los diferentes tipos de comentarios
según como fueron clasificados.

\vspace*{0.3cm}

El administrador de reputación y el publicador de comentarios aceptados en redes sociales se suscriben solo a comentarios aceptados.
El publicador, en particular observa los que tengan en su header el nombre de usuario y contraseña de alguna red social para publicar el comentario en el perfil del individuo publicador correspondiente,
si no, lo descarta. 

Veremos en detalle como funciona el administrador de reputación en otra sección.

\vspace*{0.3cm}

El almacenador en base de datos suscribe a comentarios rechazados y aceptados ya que los guardará en las bases de datos correspondientes. Lo mismo ocurre con el manager de resultados de
comentarios, quien debe informar al front end el resultado del intento de publicación del comentario (por rechazado o publicado satisfactoriamente).

\begin{figure}[H]
    \centering
    \subfloat[]
    {\includegraphics[width=0.9 \textwidth]{./img/procesador_de_comentarios.pdf}}
\end{figure}

\newpage
\subsection{Administrador de Reputaci\'on}

Uno de los componentes suscriptos a los comentarios que ingresan en el bus donde los procesadores de comentarios publican, es el Administrador de 
Reputación.

El administrador de reputación suscribe a los comentarios etiquetados como aceptados por el procesador y los recibe mediante un Detector de referencias
a otros usuarios. Este chequea si el comentario hace referencia a otro individuo publicador existente en el sistema, leyendo de la base de usuarios existentes.

De no hacer referencia a ningún individuo, el comentario es descartado. De lo contrario, se encola en el pipe del Analizador de positividad.

\vspace*{0.3cm}

El analizador de positividad de comentarios desencola comentarios y decide si los mismos son de carácter positivo o negativo. En función de eso, 
cuanto se debe incrementar o decrementar la reputación del individuo publicador al que se hizo referencia (indicado previamente por el Detector de referencias).

Para los comentarios que no se pueda decidir si es positivo o negativo, el Analizador puede consultar la base de datos de reputaciones en busca del 
historial del individuo publicador al que se hace referencia para ``desempatar''.

\begin{figure}[H]
    \centering
    \subfloat[]
    {\includegraphics[width=0.9 \textwidth]{./img/administrador_de_reputacion.pdf}}
\end{figure}

Finalmente el Modificador de reputación de usuarios(incluye individuos publicadores) desencola los pedidos de incremento/decremento de reputaciones y los refleja en la base leyendo su 
valor anterior y decrementando/incrementando lo indicado.
Vía front end web, el modificador puede recibir solicitudes de incremento de reputación, recordemos que estas son producto de los "me gusta" que algún 
individuo publicador que ingresó vía red social realizó sobre algún comentario.


\subsection{Comentario final}

En un principio, consideramos la idea de incluir un incrementador y un decrementador de reputaciones en el administrador de reputaciones, para que leyeran y escribieran la base de reputación por usuario.

Esto lo pensamos para que el incremento y decremento se hiciera de esta
forma, acelerando la bajada a la base de datos.

Pero luego nos dimos cuenta de que esto ten\'ia problemas conocidos
de las bases de datos, como lost update.

Pod\'ia pasar, por ejemplo, que ambos incrementadores leyeran una misma reputación de un usuario determinado, luego el incrementador escribiera una reputación
mayor a la leida, y el decrementador pisara ese valor con uno inferior a la leída, sin tener en cuenta el update de datos que realizó el incrementador recientemente y quedando así inconsistentes los datos de la base.
Para evitar éste problema optamos por utilizar un solo componente, Modificador de reputación de usuarios, que haciera ambos trabajos (incrementar/decrementar).

\vspace*{0.3cm}

Tambi\'en considramos suponer que los administradores podían entrar al sistema via el mismo front end web que los usuarios, pero luego vimos los problemas de seguridad
que podiamos llegar a tener dado que los administradores pueden leer todas las bases de datos del sistema y escribir casi todas.
Finalmente optamos por agregar un front end exclusivo para los administradores y de esta manera disminuir la exposición.
